Performance and operation of communication networks and particularly telecommunication networks have to be carefully monitored and studied in order to assure satisfactory functioning of the networks. Vital for the performance and operation of modern communication networks is the collection of traffic measurements. Traffic measurements are used to monitor network performance, to ensure that traffic load is distributed in a desired way in the network. Performance management with traffic measurements can also be used for traffic dimensioning, to ensure provisioning of a desired service quality and contracts, for example service level agreements, and it can also serve as a basis for charge calculations, allocation of resources etc.
Traffic measurements can be of many different kinds. It may depend on the resource or service that is to be measured and different parameters can be measured. Moreover the granularity of the object being monitored may differ considerably from one managed system to another, for example from network element (NE) to all the devices within the NE etc. Entities or objects that are measured may be static, such as for example a switch port, or they may be dynamic, such as for example a communication session, e.g. an RTP (Real Time Transport Protocol) session.
Measurement data also has to be handled or processed somewhere. In known systems this is done in a managing system managing a number of managed systems or network elements. Measurement data then has to be transferred from the location where the measurements were carried out, for example from an NE, to the managing system. It is known to transfer measurement data synchronously, i.e. it may be polled by a management system but it may also be transmitted asynchronously from an NE. Measurements may be transmitted via messages or collectively as a file. The most predominant mode of measurement data transfer in telecommunication networks is via file transfer from a network element to a managing system, for example an OSS (Operation Support System). For third generation mobile networks, it is mandated that measurement data is transferred via file transfer from an NE to an OSS, cf. for example 3GPP TS 32.431 “Telecommunication Management; Performance Measurement Collection Integration Reference Point (IRP); Requirements” and 3GPP TS 32.104 V4.0.0 “Telecommunication Management; 3G Performance Management (PM), (Release 4)”. It is also known to record different forms of measurements, counters may be used or the occurrence of certain events may be recorded. Very often the collected raw measurement data from the network has to be handled by primary processing means or be pre-processed in the OSS in order to derive higher level counts or abstractions to provide meaningful data. Such pre-processed measurements are called aggregated measurements and they are formed by combining basic performance management counts in a calculation to form a more complex performance count.
One example of such a measurement in a GSM network is “% Frame Erasure Rate”. This measurement indicates what portion (i.e. percentage) of the total dropped calls in an NE are due to frame erasure conditions. It is calculated by inspecting protocol events that occur during the processing of calls by the NE. It is defined as
  100  *                                ⁢                                                  Number              ⁢                                                          ⁢                                                of                  ⁢                                                                                        ``                            ⁢              Call              ⁢                                                          ⁢              release              ⁢                                                          ⁢              events              ⁢                                                          ⁢              with                                                                                          urgency                ⁢                                                                  ⁢                conditions                            =                              9                ⁢                                                                  ⁢                to                ⁢                                                                  ⁢                                  11                  ″                                                                        ⁢                                  Number      ⁢                                        ⁢                                      ⁢      of      ⁢                          ⁢      all      ⁢                                        ⁢                                      ⁢      Call      ⁢                          ⁢      release      ⁢                          ⁢      events      
Aggregated measurements are of different complexity depending on the complexity of the underlying counters. It should be clear that a counter “Number of CS Call release events” is simpler than a counter “Number of CS Call Release events with urgency condition=9-11”, since the latter involves examination of the protocol event parameters and the former does not. Some aggregation counters are quite complex and involve the occurrence of a number of conditions in one or more events. To derive such counters, examination of a number of event parameters is required and this in turn necessitates the collection of all data related to these events and the transfer of this data to the OSS from the NE.
It should be clear that there are many applications consuming traffic measurements and the time frame of response of these applications can range from minutes to months. Many OSS applications are used for network and service optimization on timescales of tens of minutes. Data collection periods are typically 15 minutes and in some cases 5 minutes.
However, it is obvious that with the continuously growing sizes as well as complexity of networks a lot of problems are produced, amongst other things as far as performance management is concerned. For several reasons therefore, e.g. due to the response times, size and complexity of real-time network management applications, much more and more frequent data has to be collected. Another reason is that managed systems or network elements tend to become smaller than before and also more than before. For example, 3rd generation mobile access networks are expected to reach or exceed 15000 network elements in the short to medium term. This means that an enormous amount of data is needed to provide an overall picture of network performance, and data has to be fetched from most or all network elements in the network. In addition thereto modern networks are diverse in nature. The range of services is greater, network architectures have more layers and there is a greater variety of network nodes. This means that more and different types of measurements are needed and hence also for that reason more data needs to be collected.
Thus enormous amount of data, of many different types, has to be collected often in real time and moreover all this data has to be transferred to the management system, which means that there will be a high amount of data transfer merely for performance management purposes. Thus, capacity limitations can be produced in the communications network between the respective network elements and the OSS. This is becoming a critical issue, as an example a BSC with 7000 Erlang traffic and 70% GPRS traffic subscribers may have an average data transfer rate of 1.2 Mbps between the NE and OSS. In addition thereto capacity problems may be produced in the OSS due to the amount of information that has to be parsed, pre-processed and stored in very short times. There is also a need to produce reports in near real time which places an even greater load on processing and storage resources.
U.S. Pat. No. 5,687,223 for example defines an architecture and a method of selecting data from call data records using rule sets. Rules are used to configure the data fields to be selected for particular services from amongst the complete set of data fields. This is based on a so called generalized statistics engine which essentially is an adjunct processor for handling performance statistics. This solution is however not so efficient, simple and flexible and it will also easily involve capacity limitations. The amounts of data that need to be transferred will also be far too large.